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Copyright Notice 
Copyright (C) The Internet Society (1998). All Rights Reserved. 
2. Introduction 


This document describes a way to do IN-ADDR.ARPA delegation on non- 
octet boundaries for address spaces covering fewer than 256 
addresses. The proposed method should thus remove one of the 
objections to subnet on non-octet boundaries but perhaps more 
significantly, make it possible to assign IP address space in smaller 
chunks than 24-bit prefixes, without losing the ability to delegate 
authority for the corresponding IN-ADDR.ARPA mappings. The proposed 
method is fully compatible with the original DNS lookup mechanisms 
specified in [1], i.e. there is no need to modify the lookup 
algorithm used, and there should be no need to modify any software 
which does DNS lookups. 


The document also discusses some operational considerations to 
provide some guidance in implementing this method. 


3. Motivation 


With the proliferation of classless routing technology, it has become 
feasible to assign address space on non-octet boundaries. In case of 
a very small organization with only a few hosts, assigning a full 
24-bit prefix (what was traditionally referred to as a "class C 
network number") often leads to inefficient address space 
utilization. 
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One of the problems encountered when assigning a longer prefix (less 
address space) is that it seems impossible for such an organization 
to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously. By 
use of the reverse delegation method described below, the most 
important objection to assignment of longer prefixes to unrelated 
organizations can be removed. 


Let us assume we have assigned the address spaces to three different 
parties as follows: 


192.0.2.0/25 to organization A 
192.0.2.128/26 to organization B 
192.0.2.192/26 to organization C 


In the classical approach, this would lead to a single zone like 
this: 


SORIGIN 2.0.192.in-addr.arpa. 


1 

1 PIR host1.A.domain. 
2 PTR host2.A.domain. 
3 PTR host3.A.domain. 
r 

129 PTR host1.B.domain. 
130 PTR host2.B.domain. 
131 PTR host3.B.domain. 
7 

193 PIR host1.C.domain. 
194 PTR host2.C.domain. 
195 PTR host3.C.domain. 


The administration of this zone is problematic. Authority for this 
zone can only be delegated once, and this usually translates into 
"this zone can only be administered by one organization." The other 
organizations with address space that corresponds to entries in this 
zone would thus have to depend on another organization for their 
address to name translation. With the proposed method, this 
potential problem can be avoided. 


4. Classless IN-ADDR.ARPA delegation 


Since a single zone can only be delegated once, we need more points 
to do delegation on to solve the problem above. These extra points 
of delegation can be introduced by extending the IN-ADDR.ARPA tree 
downwards, e.g. by using the first address or the first address and 
the network mask length (as shown below) in the corresponding address 
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space to form the the first component in the name for the zones. 
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The 


following four zone files show how the problem in the motivation 
section could be solved using this method. 


SORIGIN 2.0.192.in-addr.arpa. 


@ IN 
ae 


; <<0-127>> /25 


SOA 


0/25 NS 
0/25 NS 
1 CNAME 
2 CNAME 
3 CNAME 


my-ns.my.domain. 


ns.A.domain. 


hostmaster.my.domain. (...) 


some.other.name.server. 


1.0/25.2.0.192.in-addr 
2.0/25.2.0.192.in-addr 
3.0/25.2.0.192.in-addr 


-arpa. 
-arpa. 
-arpa. 


; <<128-191>> /26 


128/26 NS ns.B.domain. 

128/26 NS some.other.name.server.too. 

129 CNAME 129.128/26.2.0.192.in-addr.arpa. 

130 CNAME 130.128/26.2.0.192.in-addr.arpa. 
CNAME 131.128/26.2.0.192.in-addr.arpa. 


131 


; <<192-255>> /26 


192/26 NS ns.C.domain. 

192/26 NS some.other.third.name.server. 
193 CNAME 193.192/26.2.0.192.in-addr.arpa. 
194 CNAME 194.192/26.2.0.192.in-addr.arpa. 
195 CNAME 195.192/26.2.0.192.in-addr.arpa. 


SORIGIN 0/25.2.0.192.in-addr.arpa. 


@ IN SOA ns.A.domain. hostmaster.A.domain. (...) 
@ NS ns.A.domain. 
@ NS some.other.name.server. 
r 
1 PTR host1.A.domain. 
2 PTR host2.A.domain. 
3 PTR host3.A.domain. 
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SORIGIN 128/26.2.0.192.in-addr.arpa. 


@ IN SOA ns.B.domain. hostmaster.B.domain. (...) 
@ NS ns.B.domain. 

@ NS some.other.name.server.too. 

, 

129 PTR host1.B.domain. 

130 PTR host2.B.domain. 

131 PTR host3.B.domain. 


SORIGIN 192/26.2.0.192.in-addr.arpa. 


@ IN SOA ns.C.domain. hostmaster.C.domain. (...) 
@ NS ns.C.domain. 

@ NS some.other.third.name.server. 

, 

193 PTR host1.C.domain. 

194 PTR host2.C.domain. 

195 PTR host3.C.domain. 


For each size-256 chunk split up using this method, there is a need 
to install close to 256 CNAME records in the parent zone. Some 
people might view this as ugly; we will not argue that particular 
point. It is however quite easy to automatically generate the CNAME 
resource records in the parent zone once and for all, if the way the 
address space is partitioned is known. 


The advantage of this approach over the other proposed approaches for 
dealing with this problem is that there should be no need to modify 
any already-deployed software. In particular, the lookup mechanism 
in the DNS does not have to be modified to accommodate this splitting 
of the responsibility for the IPv4 address to name translation on 
"non-dot" boundaries. Furthermore, this technique has been in use 
for several years in many installations, apparently with no ill 
effects. 


As usual, a resource record like 


SORIGIN 2.0.192.in-addr.arpa. 
129 CNAME 129.128/26.2.0.192.in-addr.arpa. 


can be convienently abbreviated to 


SORIGIN 2.0.192.in-addr.arpa. 
129 CNAME 129.128/26 
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Some DNS implementations are not kind to special characters in domain 


names, e.g. the "/" used in the above examples. As [3] makes clear, 


these are legal, though some might feel unsightly. Because these are 
not host names the restriction of [2] does not apply. Modern clients 
and servers have an option to act in the liberal and correct fashion. 


The examples here use "/" because it was felt to be more visible and 
pedantic reviewers felt that the ’these are not hostnames’ argument 
needed to be repeated. We advise you not to be so pedantic, and to 
not precisely copy the above examples, e.g. substitute a more 
conservative character, such as hyphen, for "/". 


5. Operational considerations 


This technique is intended to be used for delegating address spaces 
covering fewer than 256 addresses. For delegations covering larger 
blocks of addresses the traditional methods (multiple delegations) 
can be used instead. 


5.1 Recommended secondary name service 


Some older versions of name server software will make no effort to 
find and return the pointed-to name in CNAME records if the pointed- 
to name is not already known locally as cached or as authoritative 

data. This can cause some confusion in resolvers, as only the CNAM 


record will be returned in the response. To avoid this problem it is 


recommended that the authoritative name servers for the delegating 
zone (the zone containing all the CNAME records) all run as slave 
(secondary) name servers for the "child" zones delegated and pointed 
into via the CNAME records. 


5.2 Alternative naming conventions 
As a result of this method, the location of the zone containing the 


actual PTR records is no longer predefined. This gives flexibility 
and some examples will be presented here. 


An alternative to using the first address, or the first address and 
the network mask length in the corresponding address space, to name 
the new zones is to use some other (non-numeric) name. Thus it is 
also possible to point to an entirely different part of the DNS tree 
(i.e. outside of the IN-ADDR.ARPA tree). It would be necessary to 
use one of these alternate methods if two organizations somehow 
shared the same physical subnet (and corresponding IP address space) 
with no "neat" alignment of the addresses, but still wanted to 
administrate their own IN-ADDR.ARPA mappings. 
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The following short example shows how you can point out of the IN- 


ADDR.ARPA tree: 
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SORIGIN 2.0.192.in-addr.arpa. 


@ IN SOA 

i 

1 CNAME 

2 CNAME 

Posa 

129 CNAME 
CNAME 


SORIGIN A.domain. 


etc. 


IN 


my-ns.my.domain. ho 


1.A.domain. 
2.A.domain. 


129.B.domain. 
130.B.domain. 


SOA my-ns.A.domain. hos 
A 192.021 

PTR host1 

A 192.0.2.2 

PTR host2 


stmaster.my.domain. 


March 1998 


(aes 


tmaster.A.domain. (... 


This way you can actually end up with the name->address and the 


(pointed-to) 


address->name mapping data in the same zone file - some 


may view this as an added bonus as no separate set of secondaries for 


the reverse zone is required. 
the IN-ADDR.ARPA tree will still be done, 
inserted there need to point in the right 


Sketched below is an alternative approach 


Do however 


SORIGIN 2.0.192.in-addr.arpa. 


@ SOA 

7 

1 CNAME 

2 CNAME 

SORIGIN A.domain. 

@ SOA 

i 

7 

hostl A 

1.2.0.192.in-addr PTR 
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my-ns.my.domain. 


-A.domain. 


192.0.2.1 


Current Practice 


note that the traversal via 
so the CNAME records 
direction for this to work. 


using the same solution: 


hostmaster.my.domain. (... 


-192.in-addr.A.domain. 
„192.in-addr.A.domain. 


hostmaster.A.domain. 
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host2 A 192.0.2.2 
2.2.0.192.in-addr PTR host2 


It is clear that many possibilities exist which can be adapted to the 
specific requirements of the situation at hand. 


5.3 Other operational issues 


Note that one cannot provide CNAME referrals twice for the same 
address space, i.e. you cannot allocate a /25 prefix to one 
organisation, and run IN-ADDR.ARPA this way, and then have the 
organisation subnet the /25 into longer prefixes, and attempt to 
employ the same technique to give each subnet control of its own 
number space. This would result in a CNAME record pointing to a CNAME 
record, which may be less robust overall. 


Unfortunately, some old beta releases of the popular DNS name server 
implementation BIND 4.9.3 had a bug which caused problems if a CNAME 
record was encountered when a reverse lookup was made. The beta 
releases involved have since been obsoleted, and this issue is 
resolved in the released code. Some software manufacturers have 
included the defective beta code in their product. In the few cases 
we know of, patches from the manufacturers are available or planned 
to replace the obsolete beta code involved. 


6. Security Considerations 
With this scheme, the "leaf sites" will need to rely on one more site 
running their DNS name service correctly than they would be if they 
had a /24 allocation of their own, and this may add an extra 


component which will need to work for reliable name resolution. 


Other than that, the authors are not aware of any additional security 
issues introduced by this mechanism. 


7. Conclusion 


The suggested scheme gives more flexibility in delegating authority 
in the IN-ADDR.ARPA domain, thus making it possible to assign address 
space more efficiently without losing the ability to delegate the DNS 
authority over the corresponding address to name mappings. 
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11. 


Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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